Questions to consider

• How do we ensure that a user process doesn’t harm others?
• How do system calls work? How do they related to wrapper libraries like glibc?

Dual-mode operation

• Dual-mode operation allows OS to protect itself and components
  • User mode and kernel mode
• Mode bit provided by hardware
  • Provides ability to distinguish when system is running user code or kernel code.
  • When a user is running → mode bit is “user”
  • When kernel code is executing → mode bit is “kernel”
• System call changes mode to kernel, return from call resets it to user
• Some instructions are only executable in kernel mode

System calls

• The OS offers a number of services. How do we (applications) interface with them?
  • We don’t want to deal with the details, just the abstraction
  • The OS has ultimate control over these operations
• System calls are the “language” of communication with the OS
• Standards
  • Win32 (MS)
  • POSIX (nearly all Unix-based systems)
  • Java API for the JVM

System calls (cont’d)

• Like a function call, we push arguments onto the stack, then we call into the library that provides the system call
• Each system call has a special number, placed into a register
• Executes a TRAP instruction (switch to kernel mode)
• A logical separation of memory space
• Kernel’s system call handler is invoked, once done (but may block) may be returned to the process

System calls (cont’d)

• Table defined in the kernel: https://github.com/torvalds/linux/blob/master/arch/x86/entry/ syscalls/syscall_32.tbl
  • Note that system call tables can differ between architectures
• You can run using the table values themselves using the syscall() wrapper
  • Q: why does syscall() exist?
  • If you’re interested… There are debates https://lwn.net/Articles/771441/

Questions to consider

• What do processes contain?
• How does the OS run multiple processes at the same time?
• How are processes laid out in memory?
• How does the OS store information about each process?

Processes

• Most fundamental OS abstraction
  • Processes organize information about other abstractions and represent a single thing the computer is “doing”
• When you run an executable program (passive), the OS creates a process == a running program (active)
• One program can be multiple processes

Process organization

Multiprogramming

• Processes are the core abstraction that allows for multiprogramming: the illusion of concurrency
• OS timeshares CPU across multiple processes: virtualizes CPU
• OS has a CPU scheduler that picks one of the many active processes to execute on a CPU
• Policy:
  • which process to run
• Mechanism:
  • how to context switch between processes

Process’s view of the world

Process memory layout

OS’s view of the (process) world

Questions to consider

• What are the different process states and what causes transitions?
• What is a context switch?
• What are the two general categories of processes and how do they differ?

Process states

• As a process executes, it changes state
  • New: The process is being created
  • Running: Instructions are being executed
  • Waiting: The process is waiting for some event (typically I/O or signal handling) to occur
  • Ready: The process is waiting to be assigned to a processor
  • Terminated: The process has finished execution

Process state transitions

Process state transitions (cont’d)

Process scheduling

• OS process scheduler selects among available processes for next execution on CPU core
• Goal?
  • Maximize CPU use, quickly switch processes onto CPU core
• Maintains scheduling queues of processes
  • Ready queue: set of all processes residing in main memory, ready and waiting to execute
  • Wait queues: set of processes waiting for an event (i.e., I/O)
• Processes migrate among the various queues over their lifetime

Context switching

• When CPU switches to another process, the system must save the state of the old process and load the saved state for the new process via a context switch
• Context of a process represented in the PCB
• Context-switch time is pure overhead; the system does no useful work while switching
  • The more complex the OS and the PCB → the longer the context switch
• Time dependent on hardware support
  • Some hardware provides multiple sets of registers per CPU → multiple contexts loaded at once

Context switching overhead

• On the order of milliseconds
• If not done intelligently, you can spend more time context-switching than actual processing
• Question: Why shouldn’t processes control context switching?

Scheduling basics

• Scheduler usually makes the transition decisions; hides the details from the process/user
• Processes often characterized as one of two types by what state they spend most of their time in
  • I/O bound: work is dependent on I/O; e.g., browser, db, media streaming
  • CPU bound: work is dependent on CPU; e.g., scientific apps, cryptography
  • Why does this matter?
    • Understanding which your process is allows for optimization
      • CPU-bound? Faster CPU, parallelize.
      • I/O? Faster I/O devices, use async
• Scheduler must balance CPU- & I/O-bound processes
  • Reminder: the goal is to maximize CPU utilization

Aside: multiprocessing in mobile

• Some mobile systems (e.g., early versions of iOS) allow only one process to run, others suspended
• Due to screen real estate, user interface limits iOS provides:
  • Single foreground process controlled via user interface
  • Multiple background processes in memory, running, but not on the display, and with limits
    • Limits include single, short task, receiving notification of events, specific long-running tasks like audio playback
• Android runs foreground and background, with fewer limits
  • Background process uses a service to perform tasks
  • Service can keep running even if background process is suspended
  • Service has no user interface, small memory use

Questions to consider

• Which system calls are related to process management and lifecycles?
• How does the process hierarchy work?
• What are zombies and orphans? Why do zombies exist?

UNIX process APIs

• fork() creates a new child process
  • All processes are created by forking from a parent
  • The init process is ancestor of all processes
    • Run pstree in a terminal to see
• exec() makes a process execute a given executable (effectively replaces the process)
• exit() terminates a process
• wait() causes a parent to block until child terminates
• Many variants exist of the above system calls with different arguments

What happens during a fork()?

• A new process is created by making a copy of parent’s memory image
• Both parent and child have unique address spaces (isolated from each other, allowing for independent processing)
• The new process is added to the OS process list and scheduled
• Parent and child start execution just after fork (with different return values)
• Parent and child execute and modify the memory data independently

Process creation

• Different execution models
  • Parent & child may execute independently
  • Parent may wait for child
  • Child may create more children (Process hierarchies)
  • Parent may kill children
• Child often invokes exec() to change its memory image to a new program
• Why two steps (fork() then exec())?
  • Allows the child to change file descriptors and other settings before exec()

Process destruction

• Some operating systems do not allow child to exist if its parent has terminated. If a process terminates, then all its children must also be terminated

  • Cascading termination: All children, grandchildren, etc., are terminated.
  • The termination is initiated by the operating system

• The parent process may wait for termination of a child process by using the wait() system call. The call returns status information and the pid of the terminated process

  pid = wait(&status); 

Zombies and orphans